Systems and methods for autonomous device transacting

ABSTRACT

A system and method for verifying a cryptographic transaction includes requesting a portion of the blockchain comprising a merkle tree path; verifying a value of the cryptocurrency key using simplified payment verification; and bundling the cryptographic transaction, a block header of the cryptographic transaction, a plurality of block headers subsequent the block header of the cryptographic transaction, and the merkle tree path thereby forming a cryptographic currency receipt.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.62/252,306, filed 6 Nov. 2015, which is incorporated in its entirety bythis reference.

TECHNICAL FIELD

The inventions of the present application relate generally to theelectronic connectivity and communications fields, and more specificallyto improved systems and methods for implementing secure and privatecommunications between devices.

BACKGROUND

In many centralized systems, many devices across great and smalldistances can achieve heightened levels of connectivity and interactionwithout being physically connected to each other and thus, are able toconnect and communicate with one another wirelessly. These centralizedsystems for connecting these devices, however, are accompanied withseveral disadvantages that limit connectivity in remote locations, limitthe autonomy of the devices operating in the centralized systems, andtherefore, do not allow for optimal connectivity, autonomoustransacting, and communications between and through the devices.

Additionally, due to the inherent lure of abuse and exploitation bycentralized systems, all of these economic elements, digital andphysical, with existing systems or new products, must be fundamentallyautonomous and distributed in nature in order to maximize theirpotential. It is only in autonomous and distributed environment thatmarkets can naturally emerge, balanced and maximizing benefit for allthose involved.

The commonly referred to proposal to evolve the Internet to optimize forthe “Internet of Things” has become synonymous with connectedthermostats, pet collars, and toothbrushes. While the ability to buildconnectivity between devices like these is novel, there is a possibilitythat it may not realize the full potential of digitally connecting thephysical world of things together. When a device can only connect withsimilarly-manufactured devices, and each of them can only connect withtheir manufacturer-approved cloud service, and thus, the vast majorityof value that the device could have provided over its lifetime isseverely hindered since it is strictly tied to a cloud-based interactionplatform.

These new economic actors—e.g., the devices themselves—must beprincipally independent actors from centralized authority (e.g.,manufacturers and connectivity servers) to unlock the vast majority ofvalue associated therewith. Including—and especially—from themanufacturers of the devices themselves. It can be a very riskyproposition to continue to give central authority, whether a nationstate or a corporation, the reach and control capable of this new typeof connected device. These autonomous and fully interconnected devicesshould retain full control and complete privacy at the device providingthe coupling and creating the economic value.

But in order to realize such prospective technical environments wheredevices are independent actors; the technical functions involved inconnectivity including discovery, interacting, and even transactingvalue between devices and with people, the entire protocol stack,systems, and methods governing these technical functions must bere-evaluated from the ground up. Thus, there is a need in the deviceconnectivity and communication field to create new and useful systemsand methods for implementing an environment for interactivity ofautonomous devices without or independent of a central authority forgoverning interaction there between and consequently, enhancing thelevels and quality of connectivity achievable with such networks anddevices.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic representation of a system of a preferredembodiment of the present application;

FIG. 2 is a schematic representation of a component of system of apreferred embodiment of the present application;

FIG. 3 is an example process flow of a method of a preferred embodimentof the present application;

FIG. 4 is an example process flow of a method of a preferred embodimentof the present application;

FIG. 5 is an example process flow of a method of a preferred embodimentof the present application; and

FIG. 6 is an example process flow of a method of a preferred embodimentof the present application.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of the preferred embodiments of the inventionsare not intended to limit the inventions to these preferred embodiments,but rather to enable any person skilled in the art to make and use theseinventions.

DIST Protocols

In the present application, a set of protocols called DistributedSentient Transactions (DIST), are implemented in the systems and methodsdescribed herein to provide a minimum set of requirements necessary torealize autonomous, decentralized devices.

In addition to the capabilities described of DIST and other novelprotocols described herein, there are two fundamental requirements thatare cornerstone for implementing a truly decentralized connected deviceenvironment. The baseline of these requirements revolve around securityand privacy.

Security and privacy as two concepts that are sometimes usedinterchangeably, and while these concepts are related, they are not thesame thing. For instance, in the realm of connectivity devices, securityentails guaranteeing that the identity given to a device and theinformation transmitted by and between devices are what the device(s)states it is, without tampering, interference, and modification withintransit, at the time of transmission, and/or at the time of receipt.Security sometimes also includes enciphering information so that theinformation is not readable by any other entity but the sender andreceiver. Privacy, on the other hand, entails preventing others outsideof the intended recipient to gain information related to or about thetransaction or transmission between two devices or parties. Exploitingprivacy could be as simple as eavesdropping, or as sophisticated asdeep-packet inspection or timing attacks to determine additionalinformation about the transaction or transmission. Thus, in order fordevices to be truly autonomous, they must also have enough basiccapabilities, at the device level, in both privacy and security tomitigate their vulnerabilities to security and privacy attacks thatwould otherwise render the devices disabled or ineffective for theirintended purposes with the simplest effort (e.g., hacking).

Accordingly, DIST weaves security and privacy throughout the entirecollection of protocols that make up the composition for DIST. WhileDIST protocols, in some embodiments, reduce efficiencies in someprocesses, the benefit obtained by enhanced security and privacy faroutweigh the drawbacks in efficiencies. A fundamental assumption, inmany embodiments described herein, is that any hardware the DIST stackof protocols runs on will have access to a hardware cryptographicco-processor to securely generate, manage, and store cryptographickeys—and when necessary, to accelerate computation-intensive encipherand decipher processing and to ensure tamper-resistant cryptographiccode. Security must be trusted at the lowest level of the hardware ofthe device, or it is possible that all higher-level promises of securityand privacy become indefensible.

Privacy must also be adhered to at the very lowest levels. Telehashprotocol is a primary communication protocol in the DIST protocol stack,and along with a sub-protocol of Telehash called TMesh, Telehashprotocols provide maximized communication privacy between any twoendpoints. Therefore, under such protocols, encrypted communication isenforced, no metadata is ever leaked in communications and theoperations of devices, and perfect forward secrecy is required.

The DIST protocol has been designed to run on a myriad of hardwareplatforms, from laptops and embedded computers all the way down tomicrocontroller-based systems such as wearables and wireless sensors.Thus, it shall be understood that DIST protocol can be run and/orapplied to any type of device or element with sufficient computationaland/or processing abilities to execute DIST protocols.

Blockname: Discovery Operation

Before any decentralized interaction between parties (e.g., devices) canhappen, there must first be a means or method to ensure both theidentity and the discoverability of a party. Identity of a party (e.g.,an endpoint or node) focuses specifically on the verifiability that aparty is who they say they are. Discovery focuses on the ability to findthe network location of the party, given a known identifier of thatparty. Blockname primarily works to solve the discovery problem. But italso solves the identity verifiability problem in concert withTelehash—the secure communication protocol.

Blockname works on a novel premise, which is: leverage almost all of theexisting Domain Name System (DNS) infrastructure that is currently usedfor Internet name resolution for domain names to Internet protocol (IP)addresses. Except, instead of relying on ICANN and its 13 root nameserver delegates to be the final source-of-truth, replace the 13 rootname server delegates with the Bitcoin blockchain or other digitalledger technologies operating without a central administrator. Blocknameuses the blockchain as a replacement start of authority (SOA) for normalDNS resolution, as well as to resolve alternative domains and customtop-level domains (TLDs). Blockname provides identity and discovery in acompletely distributed manner—no registrars, root servers, or centralauthorities required further enabling the autonomy of the devicesoperating thereunder.

Blockname solves an underlying issue with existing name resolution anddecentralization. DNS is not fundamentally decentralized in that at itsroot, there is a federation of 13 servers run by a loose conglomerate oforganizations, under the singular ICANN DNS Root Server System AdvisoryCommittee. However, this root zone is actually controlled bygovernmental entities. The government entities approve all changes tothe root zone file as requested by 1.

In order to replace the role of ICANN in Blockname, there exists anotion of notaries. Notaries are a collection of individuals ororganizations who vouch for the authenticity of names posted within aBlockname-based system. Notaries can use several means or methods toguarantee authenticity, from traditional ways such as confirmingbusiness licenses or personal identities to using already-establishedmeans to confirm identity, such as SSL certificate authorities (CAs). Toprevent land-grabs and squatting, it is expected that the earliestnotaries will leverage existing efforts from SSL certificate authoritiesin order to bootstrap Blockname. As the Blockname protocol matures andsees greater use, notaries will likely expand to use additional means tovalidate identities.

On the software side, a Blockname Resolver is provided which acts like atraditional DNS cache and recursive resolver. Blockname Resolver willresolve all queries via regular DNS first, and only when those queriesfail will Blockname Resolver use any names that come from theblockchain-based hints. In this mode, Blockname always acts as a backupfor any existing valid DNS names and only provides additional resolutionfor unregistered domains or unsupported Top-Level Domains (TLDs).

In the background, Blockname Resolver continuously indexes all newlybroadcast blockchain transactions that have a valid hint—any OP_RETURNstarting with a *—storing only the unique hints that have the largestvalues associated with them. The value of the hint's own output—whatcould be considered the “burned” value in Satoshis—must be larger forthe new hint to replace a previous one of the same name. In this way, anold host name or IP address can be updated by simply creating a newblockchain transaction with a higher value assigned to it. Since aSatoshi is 1/100,000,000 of a Bitcoin, it is extremely low cost toupdate Blockname records.

The other software component, the Blockname Notary, verifies that thenewly broadcast Blockname transactions are from an authorized agent ofthat name. It shall be noted that the Blockname Resolver will have alist of valid notaries in it—much like web browsers have a list of validcertificate authorities that are used to confirm authenticity for website SSL certificates. Each Blockname Resolver instance can modify thelist of valid notaries, but a default list is also provided.

While individual device names and subdomains can both use Blockname,they may not scale well depending on how the combination is utilized.Inefficiencies arise if it is attempted to store every device identityinside the blockchain directly. Larger namespaces, such as a customTLDs, are formed by designated public Blockname resolvers advertisingtheir existence to each other and building a distributed hash table(DHT) index for a TLD from those advertisements. The DHT index is thenused to dynamically resolve any names with that TLD, allowing forephemeral and alternative uses on a custom TLD that do not require atransaction per name or traditional DNS registration.

Telehash: Secure Communication Protocol

Once verifiable identity and lookup capabilities are available throughBlockname, Telehash allows devices to establish secure communicationdirectly with each other. Telehash, simply put, is a lightweight networkprotocol with strong encryption to enable communication across multipletransports and platforms. A lightweight interoperable protocol withstrong encryption to enable mesh networking across multiple transportsand platforms. Each endpoint generates its own unique public-key basedaddress (e.g., a hashname) to send and receive small encrypted packetsof JSON (with optional binary payloads) to other trusted endpoints. Anendpoint may also provide routing assistance to others for bridgingacross different transports and to help negotiate direct peer-to-peerlinks.

Encryption is end-to-end, and is required one hundred percent (100%) ofthe time. It is impossible to disable encryption in Telehash. There isstrict privacy, where no content, metadata or identity is ever revealedto third-parties. Telehash runs well on embedded, mobile, and desktopcomputing classes of hardware. Several underlying transport protocolsare supported, so Telehash can run cleanly on top of very commonnetworking protocols currently in use today. Lastly, there are manynative implementations of Telehash supporting a large number ofprogramming languages.

Telehash could be considered a next generation iteration of the bestparts of the XMPP protocol. XMPP is a protocol created by Jabber tofacilitate instant messaging between entities in a federated manner.Federation is similar to decentralization, except that in XMPP's case,federation means that anyone could run their own instant messagingserver, and servers could communicate with each other. Instant messagingclients would connect to servers to send messages to each other on theirclients' behalf. This was a much better model than the silos of theday—most notably AOL Instant Messenger (AIM). At the height of XMPP'spopularity, over 1 billion people used it daily to communicate. BothGoogle Chat and Facebook Messenger used it as their messaging protocol.However, federation led to consolidation over time. Early on, there werethousands of XMPP servers, and as time went on, the number of serversdecreased to just a dozen or so.

Telehash takes the best parts of XMPP, and addresses the deficienciesfound by having XMPP deployed at such a large scale. The most importantchanges Telehash brings are in the areas of protocol verbosity, privacy,and addressing the drawbacks of a federated model.

As computing has become increasingly powerful and efficient, protocolverbosity is not so much a problem as it used to be. The size of theprotocol packets, the amount of processing required to encode and decodethe packets, and the overall compute overhead required to run thatprotocol are all less of a problem for today's devices than they used tobe. However, in this new era of connected devices (e.g., nodes)—many ofwhich are extremely low power and compute (e.g., low computer processingcapabilities) capability, a lightweight protocol is actually moreimportant now than it used to be. Telehash can run on devices as smallas ARM Cortex Mo+class: a 32-bit microcontroller running at 48 MHz with32 kB of SRAM. No floating point processor and no memory controller isnecessary. Because of the proliferation of low-power connected devices,Telehash must be able to run across all devices natively in order toallow true end-to-end communication. It is important to note that, indevice classes as small as these, it is often beneficial to leverage ahardware-based crypto-accelerator chip, not only to increasecryptography performance, but for secure key storage as well. Acrypto-accelerator chip can be integrated or otherwise, included in anumber of different manners of a circuit board. A significant purpose ofthe crypto-accelerator chip, as alluded to above, is to load off verycomputing intensive tasks of encryption/decryption andcompression/decompression. In such cases, the acceleration is oftenachieved by doing particular arithmetic calculations in the hardware.Accordingly, by including a crypto-accelerator chip in addition to amicrocontroller and/or cryptographic coprocessor on a device,significant computing efficiencies can be achieved without necessarilyhaving to increase the size of a small device having the processors andchips thereon.

In terms of privacy, XMPP originally did not handle privacyconsiderations at all. Only at a later time was work done withintegrating Off-The-Record2 (OTR) functionality into XMPP. OTR broughtstrong encryption, authentication, deniability, and perfect forwardsecrecy to XMPP. Telehash handles these capabilities natively within itsprotocol, without the need to have OTR functionality built on top of it.By performing these OTR-type functionalities natively in Telehashprovides a significant benefit of computing efficiencies by a computerprocessor since there is only one protocol to be process for a secureand private communication rather than using two disparate protocols incombination.

Lastly, a federated model may be insufficient, as it has been seen withXMPP. True end-to-end networking is necessary to avoid the consolidationof federated systems as seen in the XMPP environment. The consolidationof the federated systems in the XMPP environment raises the same and/orsimilar issues apparent in systems having a central authority.Specifically, systems having central authorities governing, managing, orotherwise interacting with multiple devices may be compromised andtherefore, affecting multiple and if not all devices in a network. Thisconfiguration should be avoided to mitigate the possibility ofcompromise.

Before getting into the underlying process of Telehash, a relevant termsglossary is provided in the following paragraphs which may be helpfulwhen discussing the operation of Telehash, to avoid confusion with othernetwork protocols.

Packet refers or relates to an encapsulated format for JavaScript ObjectNotation (JSON) and binary data using an encoding format that allowscombined JSON and binary data

Hashname refers or relates to an endpoint identifier, calculated fromits public key Endpoint, which refers or relates to a participant in theTelehash network identified by a single hashname.

Message refers or relates to an asynchronous encrypted packet betweentwo endpoints; Channel, which refers or relates to a virtual stream thatallows two endpoints to exchange data reliably or unreliably.

Chunking refers or relates to a packet is chunked into smaller piecesfor low-MTU or streaming transports.

Cloaking (or Masking) refers or relates to method used to hide Telehashtraffic on the wire by randomizing all data sent in a network ofendpoints.

Exchange refers or relates to the currently encrypted session statebetween two endpoints; Handshake, which refers or relates to a messagetype used to establish an encrypted session for channels; Link, whichrefers or relates to a connection between two endpoints either directlyor via a router; Mesh, which refers or relates to a number of links withactive encrypted sessions over any transport; participants in the meshare called endpoints.

Router refers or relates to an endpoint that will facilitate link setupbetween two other endpoints; Transport—underlying network responsiblefor packet transfer.

The core entity in a Telehash network is the endpoint. Endpoints can beembedded devices, web browsers, mobile phone apps, or server daemons.They are simply the original sender, or the final recipient of anycommunication. Each endpoint has a globally unique 32-byte orsimilar-sized address, called a hashname. This hashname is how endpointsidentify themselves and other endpoints.

Endpoints establish secure communication with other endpoints by firstestablishing a link—either directly or through a router. These links canuse any available underlying network transports such as User DatagramProtocol (UDP), (Transmission Control Protocol) TCP, or even Bluetooth,short-range communications (e.g., radio), long-range sub-gigahertzradio, or a combination thereof. Once the link is established betweenthe endpoints, a handshake message occurs to create a secure exchange onthe link between the endpoints.

Once this secure link is established, one or more channels can beestablished on this link. A channel is analogous to a traditionalnetwork socket.

Once one or more channels are established securely, packets are passedbetween them directly. A collection of links to many endpoints isconsidered a mesh.

When an endpoint does not already know how to find another endpoint, itwill request help from a router. The router will facilitate a link setupbetween the two endpoints. Once the link is set up, the router is nolonger a part of the link, and the two endpoints can continue toestablish links directly until one or the other is no longer at the samenetwork address.

TMesh is a sub-protocol of the Telehash system, that extends Telehashfunctionality onto low power, low bandwidth radio links. TMesh isuniquely designed to be a secure physical (PHY) and Media Access Control(MAC) protocol for long-range, sub-Gigahertz mesh networking. It bringsthe same secure, private end-to-end networking to the smallest ofembedded devices that Telehash offers in more powerful hardware, butworks within the typically high latency and low bandwidth that thesevery long-range radio transceivers exhibit.

Accordingly, TMesh is the composite of three distinct layers, thephysical radio medium encoding (PHY), the shared management of thespectrum (MAC), and the networking relationships between two or moreendpoints (Mesh).

A community is any set of endpoints that are using a common mediumdefinition and have enough trust to establish a Telehash link forsharing peers and acting as a router to facilitate larger scale meshing.Within any community, the endpoints that can directly communicate over amedium are called neighbors, and any neighbor that has a higher z-indexis always considered the current leader that may have additionalresponsibilities.

To provide proper context additional definitions of terms used withTMesh are provided: medium refers and/or relates to a definition of thespecific channels/settings the physical transceivers of endpoints use;community refers and/or relates to a network of endpoints using a commonmedium to create a large area mesh; neighbors refers and/or relates tonearby reachable endpoints in a same community; z-index refers and/orrelates to a self-asserted resource level (e.g., available powercapacity, available memory, and other capacities of the limitedcapabilities associated with an endpoint) from any endpoint; leaderrefers and/or relates to a highest z-index endpoint in any set ofneighbors; knock refers and/or relates to a single transmission; windowrefers and/or relates to a variable period in which a knock istransmitted, 2 ̂16 to 2̂32 microseconds (<100 ms to >1 hr); and windowsequence refers and/or relates to each window will changefrequency/channels in a sequence.

Regarding context about PHY, a medium is a compact 5 byte definition ofthe exact PHY encoding details required for a radio to operate. The 5bytes are always string encoded as 8 base32 characters for ease of usein JSON and configuration storage, an example medium is azdhpa5r whichis oxo6, ox46, ox77, ox83, oxb1.

Byte 0 is the primary type that determines if the medium is for a publicor private community and the overall category of PHY encoding techniqueto use. The first/high bit of byte 0 determines if the medium is forpublic communities (bit 0, values from 0-127) or private communities(bit 1, values from 128-255). The other bits in the type map directly todifferent PHY modes on transceivers or different hardware driversentirely and are detailed in the PITY section.

Byte 1 is the maximum energy boost requirements for that medium both fortransmission and reception. While an endpoint may determine that it canuse less energy and optimize its usage, this byte value sets an upperbar so that a worst case can always be independently estimated. Theenergy byte is in two 4-bit parts, the first half for the additional TXenergy, and the second half for the additional RX energy. Whiledifferent hardware devices will vary on exact mappings of mA to the 1-16range of values, effort will be made to define general buckets andgreater definitions to encourage compatibility for efficiency estimationpurposes.

Each PHY driver uses the remaining medium bytes 2, 3, and 4 to determinethe frequency range, number of channels, spreading, bitrate, errorcorrection usage, regulatory requirements, channel dwell time, andsimilar details on the transmission/reception. The channel frequencyhopping and transmission window timing are derived dynamically and notincluded in the medium.

Transmitted payloads do not generally need whitening as encryptedpackets are by nature DC-free. They also do not explicitly require CRCas all Telehash packets have authentication bytes included for integrityverification.

A single fixed 64 byte payload can be transmitted during each window ina sequence, this is called a knock. If the payload does not fill thefull 64 byte frame the remaining bytes must contain additional data soas to not reveal the actual payload size.

WIP—determine a standard filler data format that will add additionaldynamically sized error correction, explore taking advantage of the factthat the inner and outer bitstreams are encrypted and bias-free(Gaussian distribution divergence?).

Each transmission window can go either direction between endpoints, theactual direction is based on the parity of the current nonce and thebinary ascending sort order of the hashnames of the endpoints. A parityof 0 (even) means the low endpoint transmits and high endpoint receives,whereas a parity of 1 (odd) means the low endpoint receives and highendpoint transmits.

Regarding MAC, there is no endpoint addressing or other metadataincluded in the transmitted bytes, including there being no framingoutside of the encrypted ciphertext in a knock. The uniqueness of eachknock's timing and PHY encoding is the only endpoint addressingmechanism.

Every window sequence is a unique individual encrypted session betweenthe two endpoints in one community using a randomly rotating nonce and ashared secret key derived directly from the medium, community name, andhashnames. All payloads are additionally encrypted with the ChaCha20cipher before transmission regardless of if they are already encryptedvia Telehash.

Each endpoint should actively make use of multiple communities toanother endpoint and regularly test more efficient mediums to optimizethe overall energy usage. Every endpoint advertises their current localenergy availability level as a z-index (single byte value) to facilitatecommunity-wide optimization strategies.

There are two mechanisms used for enabling a larger scale mesh networkwith TMesh, communities (MAC layer) and routers (Telehash/app layer).

A community is defined by endpoints using a shared medium and theautomatic sharing of other neighboring endpoints that it has activewindows with in that medium. Each neighbor endpoint hashname is listedalong with next nonce, last seen, z-index, and the signal strength. Anendpoint may be part of more than one community but does not shareneighbor endpoint information outside of each one.

The leader is always the neighbor with the highest z-index reachabledirectly, this is the endpoint advertising that it has the mostresources available. The leader inherits the responsibility to monitoreach neighbor's neighbors for other leaders and establish direct orbridged links with them.

Any endpoint attempting to connect to a non-local hashname will usetheir leader as the Telehash router and send it a peer request, whomwill forward it to the next highest leader it is connected to until itreaches the highest in the community. That highest resourced leader isresponsible for maintaining an index of the available endpoints in thecommunity. Additional routing strategies should be employed by a mesh tooptimize the most efficient routes and only rely on the leaders as afallback or bootstrapping mechanism.

Any endpoint that can provide reliable bridged connectivity to anothernetwork (wifi, ethernet, etc) should advertise a higher z-index and mayalso forward any Telehash peer request to additional Telehash router(s)in the mesh via those networks.

While Telehash and TMesh are not expressly discussed with respect novelembodiments discussed below, it shall be understood that Telehashprotocols and TMesh protocols may be, especially if using radiocommunication, the underlying communication security and privacyprotocols, which are implemented to ensure that the embodiments andimplementations thereof are not compromised.

Overview of IoT

Ushering in a new era revolving around IoT or generally, digitalconnectivity of things (DGoT) requires a robust system for connectivityand in the view of the present application, robust methods and systemsfor implementing secure and private connectivity with or involving thosedevices and other elements that enable an IoT or DGoT environment aredisclosed. In this context, arises the several inventive conceptsdisclosed herein which provide novel and nonobvious techniques andsystems which shore up the gaps in security and privacy that exist whenIoT devices and the like connect and communicate with one another. Byshoring up the security and privacy gaps in these devices, enhances theautonomy of the devices to operate without a central authority (e.g., acentral server or the like) that may be used to manage the device'sprivacy and security considerations.

In a typical IoT environment, there may be data capturing devices and/oroperational devices, such as sensors and/or actuators which gatherinformation associated with a machine (e.g., a thing) and connect toother sensors and/or actuators to communicate the gathered information.In this basic example of an IoT environment, the transmissions of thesensors and/or actuators may be susceptible to attacks which aim toabsorb observable information about the transmission and absorb thegathered information being transmitted and often, information about thedevices, themselves. Thus, with the prevalence of meta data attacks andmeta data surveillance to wrongfully obtain information from IoTconnectivity devices, such as the sensor and/or actuator, raises animmediate concern particularly with communications between IoT devicesthat are performed over radio frequency. This is because with radiofrequency communications there is not a network access point that youhave to worry about gathering meta data from; rather, a real immediateconcern is that anybody and/or any receiver in proximity to the radiorange of the radio frequency communication can surveil the communicationand record all of the radio frequency communication in the air. There isvirtually no way to detect whether a receiver is surveilling and/orrecording the radio communication; however, if an entity chooses toinvest heavily in physical security it may be possible to mitigate theopportunities others have to monitor and capture radio frequencycommunication information between devices. This approach, however, maybe extremely expensive and cost prohibitive.

Thus, in a system that includes thousands of devices communicating witheach other over radio frequency, the issues involving wrongfulsurveillance and information capture is magnified even greater. This isproblematic because any kind of information including data managementpatterns, device management patterns, sensor recording, sensor datapatterns, type of sensors, when schedules run, actuation timing andschedules, and the like can become exposed from the meta data associatedwith radio frequency traffic. Simply put, the wrongful surveillanceand/or capture of meta data from radio frequency communications allowsthe surveilling entity to identify communication packets which have theinformation of interest since the meta data in a radio frequencytransmission usually or possibly describes the general contents of thecommunication packets. Once the general contents of the communicationpackets are known, an entity who is surveilling the radio transmissionscan then allocate resources to hacking or wrongfully obtaining thespecific contents of the communication packets. This situation can besubstantially mitigated or otherwise, completely avoided by diminishing,disguising, obfuscating, or mitigating to a zero meta data state anyuseful meta data that can be obtained by mere surveillance in a radiotransmission between two communicating parties. A zero meta data of apreferred embodiment is a state in which at least two endpoints in amesh network or otherwise, which are establishing a link, linked, orcommunicating with each do not reveal any kind of meta data to asurveilling entity, such that zero meta data is exposed. A zero metadata state ensures that the patterns, schedules, and communicationpackets of the network of endpoints are securely and privatelyprotected.

Accordingly, there are three main recordable and/or surveillable metadata attributes of a radio frequency communication between at least twocommunicating parties that the embodiments of the present applicationseek to protect using the systems, methods, and protocols describedherein. A first attribute that the embodiments seek to protect includethe channel (e.g., frequency) of communication of a transmission, asecond attribute includes a signal strength (e.g., the loudness of thetransmission or power) of a communication and/or a signal strengthemanating from the parties or devices involved in the radiotransmission, and the time of the radio transmission including a starttime, duration of transmission (e.g., total time of transmission, endtime of transmission, and even time between transmissions. Obviously, ifany of these attributes of a radio communication become accessible to awrongful observer, the content of the transmission including the data ofthe transmission can be recorded.

Thus, each of these four parameters including the three meta dataattributes and data content of a radio transmission are protected usingthe embodiments of the present application. It shall be understood that,while the present application expressly protects these forms of metadata from surveillable or noticeable exposure, any and other forms ofmeta data associated with a radio transmission or other susceptibleforms of communication can be protected, such as any other indirecttransmission signals from components of the communicating devices whenprocessing signals, such as an RF amplifier and also, meta datainformation from a tuner or detector.

While cryptography can be used to strongly secure contents or datacontents of a communication packet, it is difficult to applycryptography to protect meta data attributes of a radio transmission,such as timing, power, and frequency (e.g., channel) being used in thetransmission. Thus, the systems and protocols associated with the systemand methods of the present application can be used to protect each ofthe above-noted parameters.

As mentioned previously, in the system(s) described herein below, thereis a fundamental requirement that each of the nodes (e.g., autonomousdevices) is able to perform full cryptography protocols without anyintervention or assistance of a central authority or centralconnectivity server. This fundamental functionality of the nodes lendsto the autonomous nature of the devices required in an IoT or DCoT ofthe future.

The systems and methods required for achieving such device autonomy isdescribed below, in part, as well as in the following application, whichis incorporated by reference in its entirety:

Systems and Methods for Secure and Private Communications

Blocklet Overview

Blocklet protocol is fundamentally based on cryptography and isorganized or structured in such a manner in which any implementation ofblocklet protocol can be self-verified using the protocols therein. Theroot of blocklet protocols include the data structures available underthe JavaScript Object Signing Encryption (JOSE) stack of protocols.Specifically, the composition of blocklet protocols includes, mainly, anumber of JWTs and JWKs, as defined by the JOSE specification.

Regarding a JWT, a JWT is a JavaScript Objection Notation (JSON) WebToken (JWT), which is a compact data structure of JOSE and a URL-safemeans of representing claims or statements of information to betransferred between two parties. Essentially, JWT is a compact claimsrepresentation format intended for space constrained environments. Aclaim in a JWT is encoded as a JavaScript Object Notation (JSON) objectthat is used as the payload of a JSON Web Signature (JWS) structure oras the plaintext of a JSON Web Encryption (JWE) structure, enabling theclaims to be digitally signed or integrity protected with a MessageAuthentication Code (MAC) and/or encrypted. Accordingly, a claim is apiece of information asserted about a subject.

Additionally, the contents of a JOSE Header for a JWT describe thecryptographic operations applied to the JWT claims. If the JOSE Headeris for a JWS, the JWT is represented as a JWS and the claims aredigitally signed or MACed with the JWT claims being the JWS payload. IFthe JOSE header is for a JWE, the JWT claims being the plaintextencrypted by the JWE. A JWT may be enclosed in another JWE or JWSstructure to create a nested JWT, enabling nested signing and encryptionto be performed.

A JSON Web Key (JWK) is a JSON data structure that represents acryptographic key.

A JWS represents content or claims of a JWT that is secured with one ormore digital signatures or Message Authentication Codes (MACs) usingJSON-based data structures. Thus, JWS provides the capability for areceiving party of an encrypted message or the like to verify a creatorof the message.

A JWE represents encrypted content of a JWT also using JSON-based datastructures. Applying JWE to encrypt JSON content provides the capabilityto allow or the intended recipient to decrypt and read the content.

Accordingly, the blocklet protocol stack provides a standard accesscontrol mechanism for devices using data structures in the JOSE stackincluding JWTs and JWKs, which may be encrypted using at least one ofJWS and JWE or the like. In addition to providing access control of adevice between any two parties, there is another higher level activityis enabled by blocklet protocol, which is contractual enforcementbetween a device using blocklet protocols and another entity withoutintervention of an outside controlling server and/or central authority.

Generally, access control in accordance with blocklet protocols defineparties, for example, other devices allowed to communicate with thisdevice, and contractual enforcement defines under what conditions canthose allowed to communicate with this device do so and providing acryptographically secure method for doing so. The differences betweenthese concepts are subtle but important distinctions, and blockletprotocols handle both of these concepts.

Traditionally, access control was typically handled by the concept of anAccess Control List (ACL), as discussed above, which simply was acentrally-controlled list of other entities that were allowed, orblocked, from accessing the particular resource (e.g., device). However,since DIST aims to offer both access control and contractual enforcementin a single protocol (e.g., Blocklet), DIST does so in a moresophisticated and autonomous way than just using an ACL.

Significantly, Blocklet protocols add to the traditional access controlapproach using ACL in the way of defining price and receipts. BecauseDIST includes a first-class term for value transfer, access control cannow include a price at which particular access to a device implementingblocklet protocol is available, and can control access of the device ifthe appropriate price is not paid. Price is then a validation term thatmust be validated in an interaction between the device and another partyin order to grant access to one or more resources associated with thedevice.

There are several ways to define the conditions under which a device maybe accessed. In some embodiments, a first type of condition under whicha device can be accessed includes on a time-basis, where a third-partywould gain access to a device over a certain time duration. A time-basisaccess, in some embodiments, could be granted at no cost or valueexchange to select groups of external parties based on one or morepredetermined factors. In a preferred embodiment, price is added to theaccess control terms, or otherwise, recognized under DIST protocols asone of the contractual terms. If price is added to the access controlterms, then additional access control is possible, such as access bymonthly payment for use of a device, a per-day contract, or an annualcontract. In the time-basis mode, the set of functionality sold by thedevice is on a time-limited basis. The durations and price for thecontract are flexible for a set of functionality. The time-basis mode ispossible using only the blocklet protocol.

Additionally, and/or alternatively, a second type of condition underwhich a device implementing blocklet protocol could be accessed includeson a use-basis, where a customer would pay per use for a deviceresource. This could be a payment for a given sensor reading, or toactuate a machine that the device is operably connected to or operablyin communication with. In the use-basis mode, there is a set offunctionality that is sold per unit of functionality provided by thedevice. In such embodiments, the units of functionality and price forthe contracts are flexible, for an unlimited time. The use-basis mode ispossible using both the Blocklet and Penny Bank protocols, as describedherein below.

Accordingly, in the context of DIST protocols involving the Blockletprotocol, a price-enabled access control list is referred to herein as asmart contract. Though this term is used in many different contextswithin the cryptocurrency universe, the definition provided above isstrongly tied to the terms' original definition, which is that of aself-executing, self-enforcing contract implemented in software.Accordingly, in some or many embodiments, the smart contract may also bea digital mirror of a physical or orally negotiated contract and thus,is basically a computer-readable and executable form of a real worldcontract.

In conventional service-based applications, permission to interact witha device is typically granted through reference to an access controllist (ACL) such as a whitelist of privileged entities. Although moresophisticated policy frameworks exist, in general ACLs are relativelysimplistic, allowing or disallowing interaction in an all-or-nothingway. In any case, both ACLs and policy frameworks are instantiated atthe service or account level, and thus require communication with acloud-based API or other remote centralized authority in order for thedevice to enforce access decisions.

By contrast, the blocklet protocol stack leverages several innovativesolutions to enable smart contracts and autonomous device transactingwithout the need for a central authority or centrally controlled ACL. Asmentioned above, this enabled smart contract functionality includes:self-executing, self-enforcing contracts that are implemented insoftware. These smart contracts make it possible to specify theparticular conditions under which a device will interact with otherentities, without reference to a cloud service or other centralauthority. Such conditions can include price or value to be exchanged,time period(s) during which access is allowed, a per-use charge fordefined functionality, attribution for data provided, and othertransaction or interaction (e.g., contractual) terms that are requiredin some manner to govern the overall interaction of the partiesinvolved. These smart contracts or defined set of conditional parametersgoverning an interaction between entities are specified in astandardized JWT format.

System for Implementing Blocklet

With Blocklet, there are four primary components necessary: the digitalsmart contract, the physical hardware of the device, the contractissuance/renewal capability, and the blockchain that records theproof-of-payment receipt of the smart contract.

The smart contract itself represents a contractual agreement between thebuyer, the seller, the product capabilities offered for sale, thecontract term length, and any fees associated with the contract. Whatmakes this contract different from a traditional legal contract is thatit is implemented in software and generated by the same using datastructures in the JOSE stack, the smart contract is self-executing andself-enforcing, and can be bought, sold, renewed, revoked, andtransferred in a completely digital fashion. The actual terms withinthis smart contract can be nearly anything, and is usually specific tothe product and/or service.

The smart contract's terms are specified in a standardized format calledJSON Web Token (JWT), a subset of the JavaScript Object Signing andEncryption (JOSE) specification described at the following links, thesubject matters of which are incorporated by reference in theirentireties:

JSON Web Signature: https://datatracker.ietf.org/doc/rfc7515/

JSON Web Encryption: https://datatracker.ietf.org/doc/rfc7516/

JSON Web Key: https://datatracker.ietf.org/doc/rfc7517/

JSON Web Algorithm: https://datatracker.ietf.org/doc/rfc7518/

JSON Web Token: https://datatracker.ietf.org/doc/rfc7519/

This smart contract typically resides directly on the DIST-capablehardware device in a secure storage area.

The DIST-capable physical hardware is the actual electronic circuitboard module that contains the DIST stack, and physically controls thecapabilities and features of the product as well as handles the securestorage of the contract. It often includes wireless communication for acompletely standalone decentralized connectivity solution for a product,and to receive smart contracts over the air wirelessly.

As shown in FIG. 1, a schematic representation 100 is illustrated of asystem environment for implementing a transaction involving one or moredevices implementing Blocklet protocols. Specifically, the systemenvironment of FIG. 1 includes an autonomous transaction device 110, atransacting party 120, a network 130, a block chain ledger 140, and aprovisioning device 150.

The autonomous transacting device 110, as shown in more detail in FIG.2, of system 100 may be any type of device and/or software implementedon hardware of a device with capabilities of self-enforcing one or moreconditions and/or terms of a digital smart contract 150 residing on amemory 112 of the autonomous transacting device 110. Accordingly, theautonomous transacting device 110 is a principally independent actorfrom a central authority including any central server authority andincluding manufacturers of the autonomous transacting device 110. Thatis, the autonomous transacting device 110 is able to manage all of itsoperations, transactions, access controls, transactions with otherdevices and entities, an operational control of the device withoutintervention of a central authority outside of the physical device.Thus, the autonomous transacting device retains full control andcomplete privacy at the autonomous transacting device, itself, when inuse and in operation.

As shown in FIG. 2, the autonomous transacting device comprises one ormore computer processors 111 (or a main processor 111), a memory 112, acommunication interface 113. In one variation, each autonomous deviceincludes a microcontroller 114 having a small computer on a singleintegrated circuit containing a processor core, memory, and programmableinput/output peripherals. The microcontroller 114, in some embodiments,is used in lieu of the one or more computer processors 111 and in otherembodiments, the microcontroller is used in conjunction with the one ormore computer processors 111. Additionally, and/or alternatively, eachautonomous device of the plurality of nodes 110 includes a cryptographiccoprocessor 115 which is a hardware security module or component whichprovides high security and high-throughput cryptographic subsystems anda crypto-accelerator chip 116, which may be integrated with thecryptographic coprocessor 115. The autonomous transacting device mayalso include a modulator 117, an oscillator 118, a timer/clock 119, anda power supply 120.

The autonomous transacting device 110 of FIG. 2 may also includetraditional elements of a device configured for radio communication atthe communication interface 113. Thus, the communication interface 113of node 110 of a preferred embodiment includes a radio frequency (RF)scanner 121, RF transmitter 122, RF receiver 123, RF tuner 124, anantenna 125, and a RF amplifier 126.

The memory 112 of the autonomous transacting device 110 in a preferredembodiment includes one or more computer-executable instructions and/orsoftware applications with computer code for executing the functionalityand protocols of DIST including blocklet and penny bank protocols andany other functionality or protocols associated therewith, which aredescribed herein required for secure and private communications by andbetween each of the autonomous transacting device and another party.

The cryptographic coprocessor 115 of the autonomous device 110 isconfigured to implement various cryptographic processes includinggenerating, managing, and storing cryptography keys and encrypting anddecrypting cryptographically secured communications. Specifically, eachautonomous device using the cryptographic coprocessor 115 is able togenerate private/public cryptography key pairs that can be used tocryptographically secure communication links and sessions between thedevice 110 and another party.

The autonomous transacting device 110 may be any type of device, whichmay be coupled with one or more machines, instruments, components,and/or real world operational devices or elements to sense inputs and/oroutputs thereof, to perform actuation operations of one or morecomponents thereof, to perform transactions on behalf of the element ordevice to which the autonomous device is coupled, and the like. Forexample, in some embodiments, the autonomous device is a sensorintegrated onto a circuit board having cryptographic chips thereon thatis able to obtain readings and other information relating to or aboutone or more devices to which the sensor is operably coupled and/orobtain readings about the environment of the one or more devices.Additionally, and/or alternatively, the autonomous device 110 may be anactuator that performs and/or controls one or more actuation operationsof a device to which the actuator is a component and/or is operablycoupled to. In yet another example, the autonomous device may be atransaction device which brokers transactions on behalf of the device towhich it is operably coupled and/or forms a component thereof. Thetransaction may include an exchange of value for a good, service, orother product offered to the autonomous device or the device to whichthe autonomous device is coupled. In such example, the autonomous deviceacting as a transaction device is able to negotiate with other devicesand/or other autonomous devices to obtain resources for itself and thedevice to which it is coupled or provide resources from the device towhich it is coupled for a negotiated value or the like from anotherdevice or party.

The communication network 130 of system 100 may be any type ofcommunication network that is useable by the parties of a transactioninvolving the autonomous device no. The communication network 130 of thesystem 100 is preferably used only when the autonomous device no and ananother entity involved in a transaction are not able to establishcommunication using a decentralized communication means or method thatdoes not rely on a centrally controlled and/or managed communicationscheme, such as the Internet. For instance, if the autonomous device 110and a transacting party 120 cannot established a short-ranged radiofrequency communication or similar means for completing a transaction,the parties can rely on the communication network 130, as a backupcommunication network from establishing a proper communication channelor the like for completing the transaction or implementing aninteraction.

As mentioned above, the communication network 130 may be any type orkind of network that uses the Internet (e.g., GAN), WAN, LAN, or othercentralized communication network architectures to facilitatecommunications between two or more parties including transmitting andreceiving information there between.

The blockchain ledger 140 is a distributed database that maintains acontinuously growing list of records called blocks secured fromtampering and revision. Each block contains a timestamp and a link to aprevious block. The block chain ledger 140 may be a private or a publicledger.

The configuration device 150 of a preferred embodiment is configured tobe used as a trusted third party for provisioning the autonomous deviceno with a prime contract, one or more smart digital contracts, sharedsecrets used in cryptography and as an initialization and/or generally,a provisioning server for an autonomous device; however, it shall benoted that once in operation, an autonomous device operatesindependently of the configuration device 150 and do not rely on theconfiguration device 150 for access and/or operational control supportor management. The stateless configuration server is preferably amanagement server which may be used in a device/node deployment process.For example, the configuration device 150 in a provisioning process isable to generate private/public cryptograph key pairs and provision theautonomous device no with a public key pair defining who and/or whichdevices/nodes the provisioned device can trust. The prime contract thatis provisioned onto the autonomous device governs the contractualrelation between the acquirer (e.g., buyer) of the autonomous device 110and the provider (e.g., manufacturer). While the prime contract may be asmart digital contract, the prime contract governs all subsequent smartdigital contracts provided by the autonomous device either between theacquirer and the provider and also, between the acquirer and asubsequent purchaser of one or more services and/or goods provided bythe autonomous device.

The autonomous devices/nodes can be provisioned online or offline. Inoffline provisioning, it is possible to provision the devices atinitialization or at a time of manufacturing. Thus, online configurationthrough a communication network is not necessarily required; however, insome embodiments, when renewing a digital smart contract or when it isrequired to provision the autonomous device remotely, the configurationdevice 150 may be a mobile terminal or remote terminal that canwirelessly communicate with the autonomous device over the Internet orthe like to provide any provisioning downloads and the like.

It should be understood that in a transaction involving the autonomoustransacting device 110, the establishment of a cryptographiccommunication and facilitating a transaction with another party can bepurely performed offline and without an outside accessible network(e.g., LAN, WAN, GAN, etc.) or central authority (e.g., acentral/management server). The rationale for configuring the autonomoustransacting device 110 to perform cryptographic functions without anarea network or central authority is to reduce, if not, eliminate anyrequirements that the autonomous transacting device 110 will requireintervention or assistance from an outside central authority, which maybe used to compromise the autonomous transacting device 110, therebyeliminating the need for a central authority or area network enhancesthe autonomous nature of the autonomous transacting device no.

As shown in FIG. 3, a process flow of a method 300 is provided forinitializing an autonomous transacting device using blocklet protocols.At step 310, one or more conditions and/or contractual terms areidentified and defined for a digital smart contract using one or morecompact data structures. At step 320, a provisioning device (e.g.,provisioning server) provisions the autonomous device with the digitalsmart contract. At step 330, the conditions and/or terms of the smartcontract are provided to cryptographic-based ledger (e.g., blockchain).

At step 310, one or more digital smart contracts are identified anddefined. Specifically, a manufacturer and/or a provider of a devicehaving blocklet protocol modules or service using one or more blockletprotocols determines and/or generates the one or more terms forproviding a performance of a service and/or provisioning of one or moregoods in accordance with the digital smart contract to be imprinted onthe device and/or incorporated into a service. In some embodiments, theterms of the digital smart contract are negotiated between themanufacturer and an entity that will offer the services and/or goods ofautonomous transacting device.

Once the terms of the digital smart contract are identified, the one ormore terms of the digital smart contract are used to define one or moreJWTs (e.g., one or more contracts) and JWKs (e.g., one or morecryptographic keys).

Defining the one or more JWTs include one or more of the followingsteps, which can be done in any order where there are no dependenciesbetween the inputs and outputs of the steps. However, if there aredependencies in the claims, then the order of defining or creating theone or more JWTs must be followed. First step in defining a JWT includescreating a JWT claims set containing the desired claims, as shown FIG.3A. FIG. 3A illustrates a schematic representation of a JWT including aclaim set. In this case, the performance steps and value identifiedand/or negotiated terms for the digital smart contract would beconverted into one or more claim statements in the JWT(s).

The JWT illustrated in FIG. 3A includes one or more claim namesincluding “iss”, “sub”, “aud”, “exp”, “nbf”, “iat”, and “jti” where“iss” identifies the issuer of the contract, “sub” identifies thesubject of the contract, “aud” identifies the audience of the contract,“exp” identifies the expiration of the contract, “nbf” indicates a notbefore time, “iat” indicates issued at, and “jti” indicates the JWTidentifier.

As a second step, let the message be the octets of the UTF-8representation of the JWT claims set. Thirdly, define a JOSE Headercontaining the desired set of header parameters including thecryptographic operations to be performed against the message and anyother information for processing the claims. Accordingly, the JOSEHeader must conform to either the JWS or JWE specification. FIG. 3Billustrates a schematic representation of a JOSE Header. As a finalstep, the message (e.g., the payload including the claims) is digitallysigned and then encrypted, in that order.

FIG. 3B includes contains a “cty” (i.e., content type) value, which mustbe defined as a JWT.

Defining one or more JWKs to be included in the one or more JWTsincludes the following steps. FIG. 3C provides an example JWK in whichthe members of the JWK represent properties of the key. In such case,the JWK declares that the key is an Elliptic Curve key (kty), that isused with P-256 Elliptic Curve (cry), and its x and y coordinates arethe base64ur1-encoded values shown. A key identifier (kid) is alsoprovided for the key. Accordingly, the “kty” parameter identifies thecryptographic algorithm family used with the key, such as “EC” but couldalso be “RSA”, and is used to match a specific key. The “use” (e.g.,public key use) parameter identifies the intended use of the public key.The “use” parameter is employed to indicate whether a public key is usedfor encrypting data or verifying the signature on data.

At step 320, the autonomous transacting device is provisioned with thedigital smart contract. In some embodiments, the autonomous transactingdevice is provisioned with the digital smart contract at themanufacturer of the autonomous transaction device. Provisioning istypically performed in this manner when it would be difficult tootherwise provision the autonomous transacting device remotely due toconnectivity concerns when the device is implemented in remote areas.

The contract issuance software for provisioning the autonomoustransacting device usually resides on a provisioning device or serverseparate from the autonomous transacting device. This contract issuancesoftware securely generates and renews contracts, and cryptographicallysigns them before making them available to the buyer of the autonomoustransacting device. This system is typically integrated into themanufacturer's web site or mobile application, and may be made availableto buyers by the manufacturer in a number of ways including via themanufacturer's web site. However, the contract generation of thissoftware is part of the Blocklet protocol specification, and as such,any Blocklet contract issuance protocols will work to generate a newcontract to be presented.

Additionally, and/or alternatively, the autonomous transacting devicemay be provisioned with the digital smart contract remotely using amobile computing device or terminal or other computing device that isable to interact with the cryptographic circuit board of the autonomoustransaction device to download the digital smart contract thereon andcryptographically store the digital smart contract. This method ofprovisioning the autonomous transacting device with the digital smartcontract is preferred when the terms of the digital smart contract arenegotiated between and a vendor or the like. Additionally, this methodof provisioning the autonomous transaction device is preferred forautonomous devices which are currently in the field (e.g., external tothe manufacturer) and a contractual renewal is required or a new digitalsmart contract is provided with new terms.

At step 330, the digital smart contract and associated terms areprovided to a blockchain ledger. In particular, the digital smartcontract is provided to the blockchain together with details foridentifying the autonomous transacting device. By storing thisinformation at the blockchain ledger, enables the transaction involvingthe autonomous transacting device to be verified without the use ofonline central authority, such as a payment system server or the like.Accordingly, in this manner, cryptocurrency may be used as a form ofpayment to a cryptocurrency address associated with the autonomoustransaction device where the validity and verification of thecryptocurrency payment may be performed solely between the transactingparties.

Thus, the inclusion of a digital smart contract's cryptographicfingerprint and metadata to a blockchain gives a completelydecentralized but verifiable assignment of contract ownership,assignment, and payment. The manufacturer or provider of the autonomousdevice can verify by whom a particular smart digital contract has beenpaid for by checking the transaction output of the particular contractreceipt record within the blockchain. The buyer can verify that itssmart digital contract is valid and current by checking the same recordin the blockchain.

It shall be clarified that in order to truly realize a decentralizedecosystem, once an autonomous transacting device is provisioned once, itmust always be possible to ensure that device's contract can be paid forand renewed through at least one decentralized method. The opcode logicof the transaction of a blockchain must make available the ability tocontinue to pay for a device's contract renewal through that blockchainitself. The manufacturer can also provide for centralized contractissuance and renewal using their own contract issuance software, but toensure true decentralization, once a contract is issued once, the devicemust have the ability to be renewed by the cryptocurrency of theblockchain to which it is assigned. In the case of Bitcoin, this logicis added to the P2SH script of the transaction assigning the contract.

Primarily, this is so that if a device outlives the company whomanufactured the device, the buyer of that device can continue touse—and pay for—that device for as long as the device is operational,and prevents planned obsolescence. Secondarily, ensuring that devicecontracts can be renewed digitally gives devices the ability to pay thecontracts of other devices themselves. This feature maximizes the ideaof device autonomy, which is a primary objective of the entire DISTprotocol stack.

It should also be noted that more than one contract can be assigned to aparticular autonomous transacting device. This allows the decoupling ofthe device from the number and type of buyers and sellers of theservices that the particular device provides. For instance, there couldexist one contract on a device that sells its temperature data for agiven price. There could exist another contract on that same device thatsells humidity data for another price. Each of those contracts can beopen—meaning anyone can transact with them if the proper amount is paid.Or they can be closed, where transactions are only allowed to a givenwhitelist of buyers. And any number of customers can agree to anycontract terms that they have access to. So the particular device mayhave 10 different temperature customers, and 25 different humiditycustomers, utilizing the same two contracts, and all sold by the samephysical device.

Digital smart contracts can also be combined, where two sellers maydecide to chain their contracts together. In this situation, all chainedcontractual terms must be satisfied in order for the transaction tocomplete. These are called chained contracts. This allows situationswhere an OEM provides a given module to a sensor device, and thedevice's manufacturer decides to sell access to their device usingBlocklet protocols. In this situation, the OEM and manufacturer wouldeach create a contract, and chain them together with some percentagesplit agreed upon between the both of them. When the payment for thedevice is received from the buyer, both contracts must verify a paymentreceipt in order for the device to sell the features. This could also beconsidered a form of software or hardware licensing that's built rightinto the purchase of the device's functionality itself, without havingto set up licensing agreements between the OEM and manufacturer in thetraditional way with paper contracts.

As shown in FIG. 4, a process flow of method 400 illustrates one or moresteps for facilitating a transaction between an autonomous transactingdevice and another party in accordance with blocklet protocols. At step410, a transaction request is received at the autonomous transactingdevice. At step 420, the autonomous transacting device evaluates thetransaction request against the one or more conditions and/or terms inthe digital smart contract. At step 430, the autonomous transactingdevice confirms that price and/or value is provided by the partyinitiating the transaction request. At step 440, the autonomoustransacting device provides one or more resources and/or initiates theperformance of one or more services in accordance with the transactionrequest.

At step 410, an initiating party makes a request for a transaction withthe autonomous transacting device. The initiating party may be any typeof entity including a business organization, another device that isautonomous or otherwise, a person having a device with transactingcapabilities, and the like. The transaction request of a preferredembodiment may include a request for access, a grant, an extension(e.g., renewal), a request for information (e.g., sensor readings),request for routing assistance, subcontracts (e.g., JWTs with equal orlesser scope that parent smart contract) a request for performance ofsome work or service by the autonomous device, and/or a request toperform a task or provide a service in accordance with the capabilitiesof the autonomous transacting device. It shall be understood that thetransaction request shall not be limited to the above examples; rather,the transaction request may include any type of request that isconsistent with the one or more capabilities and/or resources availableto the autonomous transacting device.

At step 420, the autonomous transacting device generates an addendumbased on the transaction request. In particular, based on the blockletprotocols, the autonomous transacting device converts the transactionrequest into a format that is executable in accordance with the JOSEprotocols. Therefore, the addendum is dynamically generated by theautonomous transacting device and in a JWT format and is used to bindthe parent smart digital contract. The generated addendum must be signedby a JWK or JWT of the prime smart digital contract hosted on theautonomous transacting device and also must be signed with economicvalue (e.g., cryptocurrency). Cryptographically signing the addendumwith both a JWT or JWK of the prime contract and cryptocurrency providedby the initiating party authorizes the addendum.

The signature of the JWT or JWK of digital smart contract (e.g., primecontract) of the autonomous transacting device confirms that theaddendum makes a valid transaction request that the autonomous devicecan perform. In particular, the autonomous transacting device comparesthe transaction request (e.g., terms) of the addendum to the one or moreclaims in the exhibits of the parent smart contract of the autonomousdevice. In such a case, the exhibit is used as a reference validationfor the performance to be made under the parent smart digital contract.The exhibits in the parent smart contract lists as claims actionsperformable with an addendum. Accordingly, following the steps in theclaims of the exhibits of the parent smart digital contract allows forthe validation of digital contract formed by the addendum together withthe smart digital contract of the autonomous device. Accordingly, one ormore of the claims in the smart digital contract may require that theaddendum is signed by the autonomous transacting device, itself, as wellas a second signature of economic value. By attributing a signaturehaving economic value (e.g., cryptocurrency) by the initiating partyallows the transaction to be completed without intervention of anyoutside party and/or device, such as a payment system, and additionallyconfirms that consideration has been paid to bind the performance to bemade under the parent smart digital contract.

In some embodiments, the one or more claims of the exhibit of the parentdigital smart contract may not necessarily require a second signaturehaving economic value; rather, it is possible that the secondcryptographic signature merely identifies the initiating party, which insome cases is sufficient to bind the digital smart contract and render aperformance by the autonomous device in accordance with the transactionrequest in a validated addendum.

At step 430, the autonomous transacting device confirms the economicvalue and/or price is provided and further, confirms the value of thesignature having economic value. In embodiments where the signaturehaving economic value is a cryptocurrency signature, the autonomoustransacting device confirms that the value of the cryptocurrency usingthe blockchain. In such embodiments, the autonomous transacting deviceimplements a simplified payment verification, which is discussed in moredetail below, using only required portions of the blockchain needed toconfirm that the value of the cryptocurrency exists and that there hasnot been any double spend of said cryptocurrency value. However, itshall be understood that, if capable, the autonomous transacting devicemay use the full blockchain to confirm the value of the cryptocurrencysignature. This may be helpful in some case when the initiating party ofthe transaction is unknown, not trusted, or the value of thecryptocurrency exchange is high.

Accordingly, at step 440, once the autonomous transacting device hasvalidated the addendum and has also verified the value of thecryptocurrency signature, the autonomous transacting device performs inaccordance with the terms of the contract bound by the addendum. In suchembodiments, the autonomous provides one or more resources and/orinitiates performance of one or more services in accordance with thetransaction request.

As an example, often when discussing the ability to buy and sell withconnected devices, it's assumed that what's for sale is the data fromthe sensors on the connected device itself, or perhaps access to themachine that the connected device is attached to. However, connecteddevices that create large-scale mesh networks can also sell rawconnectivity as well. Especially when these devices bring networkcommunication to areas where it's difficult or expensive to otherwisecommunicate wirelessly. Long-range communication becomes anothersellable aspect of the device.

Consider a company that makes a connected device that monitors utilitypower poles. Perhaps the autonomous device is monitoring the status ofthe pole itself, or the power transfer efficiency of the electricitymoving through the cables attached. For the sake of this example, it isassumed that these power pole monitoring devices are running animplementation of the DIST stack.

Since DIST allows for multiple types of functionality to be sold tomultiple buyers, it's a simple extension of the same principles to sellgeneral network connectivity in addition to the sensor data monitoringthe power poles. So while power utility company may be purchasing themonitoring of power pole health through the devices deployed across allthe power poles in a given area, it's possible that others who needgeneral network connectivity could purchase it as well—not knowing orcaring that the devices that will transport their messages also happento be monitoring power poles.

Perhaps a trucking company is moving to automated telemetry for theirfleet, and the semi-trucks are outfitted with their own telemetry systemrunning a DIST implementation. And it so happens that this truckingcompany has routes that traverse very rural areas—areas where cellularaccess is non-existent or spotty at best. The semi truck's telemetrysystem would discover a DIST network provider within range of it on oneof these remote roads—the network provider being the power polemonitoring system.

Once discovered, a price can be negotiated and agreed upon between thetruck's telemetry system and the power pole device, to send a telemetrysystem message on behalf of the trucking company, routed back hundredsof miles to an Internet backhaul connection, and directly delivered tothe trucking company's back-office system. Since Telehash provides formultiple separate sockets of encrypted communication on a given node,the power pole device acts as a tiny network router that can havemultiple clients connected to it, routing data to multiple otherdestinations on behalf of each client—and paid for with differentprices.

It shall also be noted that the power utility company cannot see anydata sent on behalf of the trucking company, nor can the truckingcompany see any data sent on behalf of the power utility company. Justas multiple parties use cellular towers to gain connectivity andprivacy, one party of a cellular tower cannot see or intercept data senton behalf of another party.

Blocklet Receipts

As shown in FIG. 5, a process flow of a method 500 illustrates providinga cryptocurrency receipt for a transaction involving an autonomoustransacting device. Specifically, method 500 uses raw transactioninformation and blockchain information to verify an exchange ofcryptocurrency value and provide the autonomous transacting device acryptocurrency receipt as verification that the cryptocurrency wasactually paid as consideration for resources and/or services provided bythe device.

A cryptocurrency-receipt is defined as a cryptocurrency-based signaturethat must be presented to the autonomous transacting device thatindicates that the cryptocurrency-based signature has a verified valueexchange required by the digital smart contract. The verification ofvalue exchange is provided to the autonomous transacting device whichhosts the digital smart contract as a cryptocurrency receipt. Thecryptocurrency receipt, in some embodiments, includes: 1) the rawtransaction and information, 2) block headers for the transaction, 3)block header after the transaction that confirms the transaction, and 4)the portion of the Merkle tree necessary for performing the verificationof value.

Presenting the autonomous transacting device with the crypto-receiptauthorizes the addendum that is involved in the transaction request.Effectively, the cryptocurrency receipt acts as a cryptographicsignature that the device recognizes as an authorization to then performthe addendum. The cryptocurrency receipt of a preferred embodimentverifies the value, itself, in the value exchange. That is, the deviceperforms a cryptocurrency value verification that includes identifyingan amount of cryptocurrency required for the requested transaction,identifying one or more cryptocurrency keys exchanged in thetransaction, verifying with blockchain ledger associated with thetransaction.

While it is preferable to verify a cryptocurrency value exchange usingthe full blockchain, such verification would be difficult to performbecause the autonomous transacting device is most likely a low-memoryand low-compute power device (e.g., constrained autonomous device),which typically lacks sufficient computing resources to perform suchcomplex computations according to its existing resources. Especially, inlight of the fact that the autonomous transacting device operateswithout the assistance of an external central authority, such as acentral server or the like, which typically could perform a fullverification of cryptocurrency value exchange if provided with the fullblockchain.

Thus, in lieu of performing cryptocurrency value exchange verificationusing the full blockchain, the autonomous transacting device of apreferred embodiment performs a simple payment verification (SPV) usingonly limited portions of the blockchain associated with the transaction.

At step 510, upon receipt of a digitally signed addendum, the autonomoustransaction device identifies the cryptocurrency value required to beexchanged for performing the addendum. Specifically, in someembodiments, the autonomous transacting device identifies thetransaction request of an addendum generated to the device and comparesthe transaction request of the addendum to an exhibit (e.g., JWK) of thedigital smart contract (e.g., JWT). In such embodiments, the autonomousdevice can determine a required cryptocurrency value to be exchanged forperforming the transaction request of the addendum. That is, in mostcircumstances, the requested action, performance, and/or resource in thetransaction request of the addendum should be associated with acryptocurrency value in the digital smart contract, that if provided bythe party initiating the transaction request, should be sufficient toverify the addendum and therefore, allow the autonomous transactingdevice to perform in accordance with the terms of the addendum.

At step 520, once the cryptocurrency value for performing the addendumby the autonomous transacting device is identified or digitally signedto the addendum, the autonomous transacting device implements a simplepayment verification process in order to verify that the actualcryptocurrency value required for the autonomous device to execute theaddendum has been transferred.

The simple payment verification process, in such embodiments, is used toallow a device to operate without storing the full blockchain.Accordingly, the autonomous transacting device downloads only the blockheaders and do not download the transactions included in each block.Thus, the resulting chain of blocks, without transactions, is 1,000times smaller than the full blockchain. With this limited blockchaininformation, the autonomous transacting device, in some embodiments,cannot construct a full picture of all the cryptocurrency available forspending by the party making the transaction request because the devicedoes not know about all the transactions on the network. Accordingly,since the autonomous device only has a limited amount of blockchaininformation for verifying the exchange of the cryptocurrency value, aslightly different method for verification is required that sometimesrelies on peers to provide to provide partial views of relevant parts ofthe blockchain on demand.

Regarding SPV, SPV verifies transaction by reference to their depth inthe blockchain instead of their height. Whereas a full blockchain nodewill construct a fully verified chain of thousands of blocks andtransaction reaching down the blockchain (e.g., back in time) all theway to the genesis block, an SPV node will verify the chain of allblocks (but not all transaction) and link that chain to the transactionof interest.

Specifically, using SPV the autonomous transacting device will establisha link between the transaction and the block that contains it, using amerkle path. Then, the device waits for blocks following the transactionblock piled on top of the block containing the transaction and verifiesis by establishing its depth under the subsequent blocks. The fact thatother nodes on the blockchain network accepted the transaction block anddid the necessary work to produce subsequent blocks on top of thetransaction block is proof, by proxy, that the transaction was not adouble-spend.

Thus, using SPV, the device establishes the existence of a transactionin a block by requesting a merkle path (e.g., part of a Merkle tree)proof and by validating the proof of work in the chain of blocks.

At step 530, once the simplified payment is completed, the autonomoustransaction device bundles together as a cryptocurrency receipt two ormore of the raw transaction, the transaction block header, subsequentblock headers (e.g., 6 or so blocks), and the merkle tree path use toverify proof of work. The cryptocurrency receipt is store at theautonomous transacting device and is also used as an additionalsignature or at least, an additional verification added to an addendum.

Pennybank Overview

Once an autonomous transacting device has the capability to discoverother participants, establish a secure communication channel with them(e.g., using Telehash and TMesh protocols), and decide to trust accessfrom that device through Blocklet protocols, there needs to be a way fora device to buy and sell very small amounts of value between each otherdirectly. Penny Bank protocols sets out to solve this last problem—thatof frictionless micro-transaction capability directly between devices ina very lightweight way, and not requiring immediate Internetconnectivity to do so or a traditional payment system, which includessome type of central authority to process the payment.

Rather, Penny Bank is a mechanism for placing some amount of value suchas Bitcoin or other cryptocurrency on hold between two parties withoutinvolving another third party, such that those two parties can thenexchange smaller amounts of value over time independently. This requiresthat one or both parties be willing to source that amount of value andhave it locked in an escrow between them, so that only throughcooperation can it be unlocked again.

Penny Bank protocols implement a zero-knowledge proof in order to allowparties to pay each other without revealing any information other thanproving to each other that their payment is valid. This mechanism alsoallows two parties to exchange payment directly with each other withouthaving Internet connectivity at the time of transfer or a centraltransacting authority, such as a central server, to reconcile thetransaction. At any time during the ongoing transactions between the twoparties, either party that has Internet access and wishes to do so orotherwise, has access to the blockchain, can request to reconcile theirbalances and value will be balanced between the two parties.

Accordingly, in cryptography, zero-knowledge proof is a method by whichone party (e.g., the prover) can prove to another party, such as averifier (e.g., blockchain) that a given statement is true, withoutconveying any information apart from the fact that the statement isindeed true.

If proving the statement requires knowledge of some secret informationon the part of the prover, the definition implies that the verifier willnot be able to prove the statement in turn to anyone else, since theverifier does not possess the secret information. Notice that thestatement being proved must include the assertion that the prover hassuch knowledge (otherwise, the statement would not be proved inzero-knowledge, since at the end of the protocol the verifier would gainthe additional information that the prover has knowledge of the requiredsecret information). If the statement consists only of the fact that theprover possesses the secret information, it is a special case known aszero-knowledge proof of knowledge, and it nicely illustrates the essenceof the notion of zero-knowledge proofs: proving that one has knowledgeof certain information is trivial if one is allowed to simply revealthat information; the challenge is proving that one has such knowledgewithout revealing the secret information or anything else.

For zero-knowledge proofs of knowledge, the protocol must necessarilyrequire interactive input from the verifier, usually in the form of achallenge or challenges such that the responses from the prover willconvince the verifier if and only if the statement is true (i.e., if theprover does have the claimed knowledge). This is clearly the case, sinceotherwise the verifier could record the execution of the protocol andreplay it to someone else: if this were accepted by the new party asproof that the replaying party knows the secret information, then thenew party's acceptance is either justified—the replayer does know thesecret information—which means that the protocol leaks knowledge and isnot zero-knowledge, or it is spurious—i.e. leads to a party acceptingsomeone's proof of knowledge who does not actually possess it.

The Penny Bank protocols, which implements zero-knowledge proof, areparticularly helpful with microtransactions and/or micropayments inwhich the transaction costs are high relative to the overall value ofthe transaction amounts. In a traditional blockchain transactioninvolving cryptocurrency, the cryptographic costs for creating atransaction for each of the microtransactions is high. For instance, iftwo parties contemplated ten microtransactions, then each of the tenmicrotransactions would require a separate cryptographic transaction tobe created in the blockchain therefore multiplying the cost oftransacting between the two parties by ten. However, using Penny Bank,the cryptographic costs are significantly reduced because only a limitednumber of cryptographic transactions are necessary. For instance, thenumber of transaction incurring significant cryptographic expense due tothe use of block chain may be limited to as little as two transactions.

In many common micro-transaction scenarios, there is some prior trust orreputation with one of the parties (such as service providers) wherehaving some funds locked in an escrow with them is not very risky. Whenthere is limited or no trust, then the locked value should be small toreduce the risk, the only side-effect being a larger percentage of feeson the transaction to fund it.

In particular, as shown in FIG. 6, the process flow of method 600implementing the Penny Bank protocols for facilitating microtransactionsand/or micropayments.

At step 610, a sidechain for the microtransactions is created. Asidechain is separate from the main blockchain but would beinteroperable to allow for a transfer of cryptocurrency assets betweenthe sidechain and the main blockchain. Accordingly, the sidechain is ablockchain that runs in parallel to the main blockchain which extendfunctionality through interoperable blockchain networks allowingdecentralized way of transferring/synchronizing cryptocurrency tokenbetween the two chains.

Sidechains are decentralized like the blockchain. The sidechaincomprises a set of secrets for incremental performance of an overalltransaction or for each microtransaction in a set of microtransactionsbetween two parties.

At step 620, a set of shared secrets or key pairs are generated prior toperforming the microtransactions and prior to establishing an escrow atthe main blockchain. Each key in the pair is split between thetransacting parties and can be exchanged in order to complete onemicrotransaction of a set of microtransactions. The set of key pairsprovided to the transacting parties may be based on simple hashing(e.g., using 256 hashing) or similar method thereby reducing thetransaction costs significantly.

At step 630, the parties to the transactions negotiate a simple escrowwhere the party making the transactions request sets aside funds for thetransactions (e.g., a series of microtransactions), which is guaranteedto be available to the two parties. The cryptographic escrow is createdat the main blockchain and only when both parties cryptographically signthe escrow can the funds of the escrow be released. Accordingly, all ofthe key pairs or shared secrets between the parties are provided to theescrow at the blockchain. In this way, the blockchain acting as a thirdparty verifier can implement zero-knowledge proofing if one or both ofthe parties want only a portion of the funds set aside in the escrowreleased.

Thus, if either party stops cooperating for any reason includingmalfunction and/or intentional non-cooperation, then the funds at thatpoint remain frozen until cooperation begins again or the party seekingto have the funds released from escrow is able to prove that at leastsome of the microtransactions have been completed thereby causing theblockchain to release spent or unspent funds.

As mentioned above, in addition to locking the funds in the escrow, theparties provide all of the shared secrets generated at step 710 for eachof the microtransactions into the cryptographic escrow. Accordingly,with all of the generated shared secrets stored in the cryptographicescrow at the block chain, the block chain can be used as a third partyto verify completion of all or a portion of the microtransactions basedon the number of shared secret pairs that have been exchanged to formthe sidechain.

At step 640, the parties (e.g., the autonomous device and thetransacting party) to the transaction may exchange shared secret pairsfor each increment of a transaction that is completed or for eachmicrotransaction that is completed. Each exchanged shared secret keypair creates a block in the sidechain.

At step 650, a party to the transaction requests a release of a portionof the escrowed funds. If either of the parties ceases their performanceof the microtransactions, by either a second transacting party (e.g.,payee) failing to continue using a resource provided by a firsttransacting party (e.g., payor) or by failing to provide a resource orservice requested in the microtransactions by the second transacting, atstep 740, either party may present the sidechain to the blockchain, evenif not fully completed with all shared secrets, to release funds inaccordance with the percentage completion of the sidechain.

The blockchain in such a case would act as a third party verifier byimplementing zero-knowledge proof. The blockchain, in such embodiment,would present a challenge to the requester of the release of funds. Insome embodiments, the challenge is based on the one or more sharedsecrets or key pairs escrowed at the blockchain. In this way, if therequester intends to prove that 50% of the microtransactions have beencompleted and that 50% of the key pairs have been exchanged, therequester could most likely respond to a challenge from the blockchainshowing that a key from the key pair of the other party is 50% percentup the chain.

Then, the blockchain can compare the key to the key pairs stored inescrow to the key pair exchanged in the sidechain to determine apercentage completion of the microtransactions. In this instance, theblockchain may confirm that the key from the other party is 50% up thechain and would release 50% of the funds to the payee and refund theother 50% of the funds to the payor.

The current implementation of Penny Bank currently only focuses on thecore locking mechanism and exchanges. It is possible to add timelocksand create more complex transactions that further reduce the risk offunds remaining locked at an escrow account

The system and methods of the preferred embodiment and variationsthereof can be embodied and/or implemented at least in part as a machineconfigured to receive a computer-readable medium storingcomputer-readable instructions. The instructions are preferably executedby computer-executable components. The computer-readable medium can bestored on any suitable computer-readable media such as RAMs, ROMs, flashmemory, EEPROMs, optical devices (CD or DVD), hard drives, floppydrives, or any suitable device. The computer-executable component ispreferably a general or application specific processor, but any suitablededicated hardware or hardware/firmware combination device canalternatively or additionally execute the instructions.

Although omitted for conciseness, the preferred embodiments includeevery combination and permutation of the various system components andthe various method processes.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims.

We claim:
 1. A system for verifying a cryptographic transactioninvolving an exchange of cryptocurrency with an autonomous device, thesystem comprising: a blockchain; a transacting entity; an autonomoustransacting device comprising: (i) a cryptographic processor; (ii) acryptographic storage medium having cryptographic code stored thereon,that when executed by the cryptographic processor performs: identifyinga cryptographic transaction involving an exchange of a cryptographiccurrency key; requesting a portion of the blockchain comprising a merkletree path; verifying a value of the cryptocurrency key using simplifiedpayment verification; bundling the cryptographic transaction, a blockheader of the cryptographic transaction, a plurality of block headerssubsequent the block header of the cryptographic transaction, and themerkle tree path thereby forming a cryptographic currency receipt.
 2. Amethod for verifying a cryptographic transaction involving an exchangeof cryptocurrency with an autonomous device, the method comprising: at acryptographic processor operably in communication a cryptographicstorage medium having stored thereon computer-executable code storedthereon, that when executed by the cryptographic processor performs:identifying a cryptographic transaction involving an exchange of acryptographic currency key; requesting a portion of the blockchaincomprising a merkle tree path; verifying a value of the cryptocurrencykey using simplified payment verification; and bundling thecryptographic transaction, a block header of the cryptographictransaction, a plurality of block headers subsequent the block header ofthe cryptographic transaction, and the merkle tree path thereby forminga cryptographic currency receipt.
 3. A non-transitory computer-readablemedium for verifying a cryptographic transaction involving an exchangeof cryptocurrency with an autonomous device having stored thereoncomputer-executable code that when executed by one or more of aprocessor and a cryptographic processor performs: identifying acryptographic transaction involving an exchange of a cryptographiccurrency key; requesting a portion of the blockchain comprising a merkletree path; verifying a value of the cryptocurrency key using simplifiedpayment verification; and bundling the cryptographic transaction, ablock header of the cryptographic transaction, a plurality of blockheaders subsequent the block header of the cryptographic transaction,and the merkle tree path thereby forming a cryptographic currencyreceipt.